allow HTTPClient to handle large payloads, in case the client (such as WifiClientSecure) does not #6969
Conversation
…ase the client (such as WifiClientSecure) does not
|
|
| size_t totalSent = 0; | ||
| while(_client->connected() && (totalSent < size)) | ||
| { | ||
| totalSent += _client->write(&payload[totalSent], (size - totalSent)); |
There was a problem hiding this comment.
if write returns 0 and client is still connected, that would mean that the socket is not ready to be written to. I suggest you catch this situation and delay a bit before retrying. Currently the code will try in a busy loop and on single core chips (or when code runs on the same core and WiFi) this is not a good idea.
There was a problem hiding this comment.
Something like this?
| totalSent += _client->write(&payload[totalSent], (size - totalSent)); | |
| const size_t thisSend = _client->write(&payload[totalSent], (size - totalSent)); | |
| totalSent += thisSend; | |
| if(thisSend == 0) { | |
| delay(10); | |
| } |
Should we add a delay? Or just bail out if write returns 0? I can't remember, but maybe I thought client->write was blocking?
|
@r-downing thank you for your contribution! |
I don't currently have access to the code or hardware I was working on when I encountered the issue originally, but I could try to generate a quick example if needed. Basically in any case where you send a large payload (1000's of bytes) with HTTPClient and WifiClientSecure it will get cut off. |
Yes, please. |
|
Closing because already implemented here: #8006 |
Description of Change
WiFiClient handles large write() by breaking it down and sending the whole thing in pieces, but WiFiClientSecure may just do a partial send and return the partial size, causing this to fail and return HTTPC_ERROR_SEND_PAYLOAD_FAILED
Tests scenarios
I have tested this successfully on an ESP32-S2 by posting a large jpeg file to an https server successfully.